The use of web-based systems has proliferated for many years, and as the use of web-based systems has grown, so too has the amount of data that is communicated between end-users and the web-based systems. The data communicated between the end-users and the web-based systems often includes sensitive information (e.g., credit card numbers, bank account numbers, social security numbers, driver's license numbers, etc.). Many web-based systems retain this sensitive information for various purposes. For example, some e-commerce websites store user credit card information so that the user does not have to provide that information each time they perform a transaction with the e-commerce website.
Various data security techniques and protocols have been developed to protect sensitive user data from exposure to unauthorized third parties. One such protocol is the payment card industry data security standard (PCI DSS) which was developed to increase controls for protecting cardholder data and to reduce credit card fraud caused by unauthorized exposure of the cardholder data. The PCI DSS defines various safeguards and data protection methods that should be used by entities that process, store, and/or transmit financial card information. While compliance with PCI DSS is not mandated by federal laws, many states have either referenced the PCI DSS, made equivalent provisions, or incorporated the PCI DSS into state law. Further, compliance with the PCI DSS may shield entities that process cardholder data from liability in the event that the cardholder data is breached (e.g., accessed by an unauthorized third party).
For many entities, establishing PCI DSS compliance can be a costly and time consuming process. For example, a user may enter cardholder data (e.g., credit card number, expiration date, control verification value (CVV), etc.) into a form on a website using an electronic device, such as a smart phone, tablet computing device, or other personal computer/laptop. When the user submits the form the cardholder date may be encrypted using transport layer security (TLS) and transmitted to a web server via a hypertext transfer protocol secure (HTTPS) communication link. Upon receiving the cardholder information, the web server may invoke an application programming interface (API) call that processes the cardholder information to facilitate a transaction. In addition to processing the cardholder information, the API call may create a log entry that includes at least a portion of the cardholder data, and the log may be written to storage. When the cardholder information is stored in the log entry, the cardholder data becomes at rest data (e.g., stored data), and any systems accessing and/or storing the at rest data may be subject to monitoring, auditing, and reporting for compliance with the PCI DSS. For example, when the web server stores the cardholder information at a data center, both the web server and the data center may be subject to PCI DSS compliance monitoring, auditing, and reporting to verify that the cardholder information has not been stored in an unprotected format (e.g., as unencrypted data). As the number of systems accessing the data center increases, the scope and cost of PCI DSS compliance monitoring, auditing, and reporting may also increase.
Compliance monitoring, auditing, and reporting is further complicated and becomes more costly when techniques used for compliance monitoring, auditing, and reporting are performed statically. That is, when a system is configured to perform monitoring, auditing, and reporting in a certain way based on a current state of the relevant compliance standard (e.g., PCI DSS), changes to the compliance standard may require that the entire monitoring, auditing, and reporting protocols implemented by the system, as well as safeguards, such as when, where, and how data is stored, be retooled/reprogrammed, etc. to ensure compliance under the modified compliance standard. This further increases the costs of monitoring, auditing, and reporting for compliance purposes.